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ELECTRONIC TRANSFER SYSTEM 

The present invention is an electronic transfer system and 
method for conducting on-line purchases. 

5 

Present e- commerce transaction systems do not provide many 
consumers with sufficient confidence to shop on-line. 
Consumers are concerned about security issues in using 
their credit card or debit card to make purchases. They 
10 are concerned that should their credit card information 
fall into the wrong hands, credit card owners may be 
liable for transactions not conducted by them. 

The electronic fund transfer method described in the 
15 specification accompanying the international application 
PCT/AU01/00137 provides a process that adds security to 
the transaction. 

The present invention relates to further improvements on 
20 this method. 

In accordance with the present invention there is provided 
a method of conducting an on-line transaction including 
the steps of: 
25 providing a transaction manager; 

generating a single use transaction identification; 

the transaction manager relating the transaction 
identification to banking information of a registered 
user; 

30 providing the registered user with the transaction 

identification; 

the user requesting to purchase a product or service 
having a value from a merchant, the purchase request 
including providing the transaction identification to the 
3 5 merchant; 

the merchant sending a payment request to the 
transaction manager for a fund transfer of the value from 
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the user to the merchant, the payment request including 
the transaction identification and the value; 

the transaction manager checking the validity of the 
transaction identification and disabling re-use of the 
5 transaction identification; 

checking whether the transaction identification is 
valid and if it is valid, sending an EFT request to a 
financial institution to transfer the value in funds from 
the user to the merchant, the EFT request including the 
10 banking information; 

checking whether sufficient funds are present in the 
user's bank account and if sufficient funds are present, 
the financial institution performing the transfer 
according to the banking information; and 
15 the transaction manager receiving confirmation of * the 

transfer from the financial institution and sending the 
confirmation to the merchant. 

Preferably the transaction manager generates the 
20 transaction identification. In one embodiment the 

transaction identification is a random number. Tri another 
embodiment the transaction identifier is generated using a 
formula. In yet another embodiment the transaction 
identification is generated using a random number and a 
25 formula. 

Preferably the banking information related to the 
transaction identification includes a credit card or debit 
card number, a card expiry date and a cardholder name. 

30 Alternatively the banking information includes a bank 

account number. It may additionally include bank account 
type and bank account holder information. Preferably the 
transaction identification is related to transaction 
manager information in addition to the banking 

35 information. Preferably the transaction manager 

information includes a transaction manager account number, 
and preferably a transaction manager account expiry date, 
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and a transaction manager account password. Preferably the 
transaction manager information further includes a 
transaction manager account alias. Preferably each 
relationship of a transaction identification to the 
banking information further includes a transaction manager 
account number or transaction account alias, transaction 
limit, and a transaction limit override password. 

Preferably the registered user is provided with another 
transaction identification by the transaction manager upon 
request by the registered user. Preferably registration of 
the user occurs prior to the generation of the transaction 
identification. Preferably registration of the user 
entails creation of a transaction manager user account, 
wherein the transaction manager account number is 
generated and transaction manager information is provided 
by the user to the transaction manager. Preferably the 
transaction manager confirms the further transaction 
information with the user' s financial" institution. 

Preferably the merchant is registered with the- transaction 
manager. Preferably registration of the merchant entails 
the transaction manager providing the merchant with a 
merchant identification. Preferably the purchase request 
sent by the merchant to the transaction manager includes 
the merchant identification. 

Preferably the purchase request includes providing the 
merchant with the value of the purchase. 

Preferably the transaction manager validates the 
transaction identification by checking that the 
transaction identification is related to the user's 
transaction manager account. Preferably the transaction 
manager account password is provided to authenticate the 
identity of the user providing the transaction 
identification. Preferably disabling of the use of the 



transaction identification is conducted by removing the 
relationship between the transaction identification and 
the user's transaction identification account number. 
Alternatively, the transaction identification is deleted 
5 from the user's transaction manager account information. 

Preferably the EFT request to the financial institution is 
conducted using the credit card or bank account details, 
the transfer amount (value of the transfer) and the 
10 merchant account details sent to the financial institution 
to transfer the funds according to a standard electronic 
fund transfer system. 

Preferably the financial institution sends an insufficient 
15 funds reply if sufficient funds are not present, whereupon 
the transaction manager sends an insufficient funds reply 

to the merchant. 

• - _ 

In one embodiment the confirmation of "the transfer sent. 

2 0 from the financial institution to the transfer manager is 

the same as the confirmation message sent from the* 
transaction manager to the merchant. In another embodiment 
the confirmations are different. 

25 In one embodiment the method of the step of disabling re- 
use of the transaction identification is provided by the 
formula for generating the single use transaction 
identification including an increment in the issue of the 
other (next) transaction identification. Preferably the 

3 0 method of generating the transaction identification 

includes providing a check sum digit or character in the 
transaction identification. Preferably the transaction 
identification is a number. 

35 Preferably conf irmation of transfer of funds is sent from 
the merchant or transaction manager to the user. 
Preferably this confirmation is sent in the form of an e- 
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mail message. 

Preferably the transaction identification is issued to the 
user in an on-line environment, such as via the Internet. 
5 Alternatively the transaction identification is provided 
to the user by a telephone interface system. Alternatively 
the transaction identification is issued to the user by 
sending the transaction identification to a portable 
storage device held by the user. Preferably the. user can 
10 activate transfer of the transaction identification from 
the portable device to the merchant. Preferably the 
portable storage device can store a plurality of 
transaction identifications . 

15 Preferably a plurality of transaction identifications may 
be provided to the user. Preferably the transaction 
manager manages a plurality of registered users each 
having a plurality of transaction identifications 
available for use in making a purchase. 1 : 

20 ~ - . " - 

Preferably the transaction manager registers a plurality 
of merchants. Preferably the transaction manager can 
conduct electronic transfers between a plurality of 
financial institutions . 

25 

Also in accordance with the present invention there is 
provided a method of conducting an on-line transaction 
including the steps of: 

providing a transaction manager; 
30 generating a single use transaction identification; 

the transaction manager relating the transaction 
identifier to banking information of a registered user; 

providing the registered user with a transaction 
identification; 

35 the user requesting to transfer an amount from a user 

account to another account, the transfer request including 
providing the transaction identification and amount to the 
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transaction manager; 

the transaction manager checking the validity of the 
transaction identification and disabling re-use of the 
transaction identification; 
5 if the transaction identification is valid, sending 

an EFT request to a financial institution to transfer the 
amount of funds from the user's account to the other 
account, the EFT request including the banking 
information; 

10 if sufficient funds are present, the financial 

institution performing the transfer according to the 
banking information; and 

the transaction manager receiving confirmation of the 
transfer from the financial institution and sending the 

15 confirmation to the user. 

In accordance with the present invention there is provided 
a system for conducting an on-line transaction including: 
means for a transaction manager; , jC . 
20 means for generating a single use transaction 

identification; 

means for arranged to relate the transaction 
identifier to banking information of a registered user; 
means for providing the registered user with a 
25 transaction identification; 

means for the user requesting to request to purchase 
the product or service having a value from a merchant, and 
providing the transaction identification to the merchant; 

means for the merchant to send a payment request to 
30 the transaction manager, the payment request including the 
transaction identification and the value; 

means for the transaction manager including means for 
checking the validity of the transaction identification 
and disabling re-use of the transaction identification; 
35 means for sending an EFT request to a financial 

institution to transfer the value in funds from the user 
to the merchant, if the transaction identification is 



valid, the EFT request including the banking information; 

the transaction manager further including means for 
receiving confirmation of the transfer from the financial 
institution and sending the confirmation to the merchant. 

5 

In order to provide a better understanding of the present 
invention, a detailed description will be provided of a 
preferred embodiment of the present invention, in which: 
Figure 1 is a schematic representation of 
10 communication between participants of the transaction 
system of the present invention; 

Figure 2 shows a schematic diagram showing massages 
between a user and the transaction manager and an external 
organisation or institution in the process of setting up a 
15 transaction manager account for the user; 

Figure 3 is a schematic representation showing 
communication between a merchant and transaction manager 
in a process for a merchant to apply for 'a 'transaction 
manager account; . " * 

20 Figure 4 is a schematic representation showing 

communication between a financial institution and a 
transaction manager in the setting up of an account with 
the transaction manager; 

Figure 5 is a schematic representation showing 
25 communication between a user and a merchant for the 
purchase of a product or service; 

Figure 6 is a schematic representation showing 
communication between a merchant and transaction manager 
in the purchase of a product or service; 
3 0 Figure 7 is a schematic representation showing 

communication between a transaction manager and a 
financial institution or bank in the purchase of a good or 
service; 

Figure 8 is a schematic representation showing 
35 communication between the transaction manager and the user 
and the merchant confirming payment of purchase; 

Figure 9 is a flow diagram showing steps involved in 
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the application of an account with the transaction 
manager; and 

Figure 10 is a flow diagram showing steps involved in 
the process of the user making a purchase. 

5 

Referring to Figure 1 there is shown a system for 
conducting financial transactions 10, which includes a 
transaction manager 12, which is a trusted intermediatory 
that provides services between users 14, e-commerce 
10 merchants 16 and financial institutions 18. In particular 
the transaction manager 12 is an intermediatory that each 
user can trust to conduct electronic transactions on 
behalf of the user. 

15 Users 14 can communicate with a transaction manager 12 
over the Internet 20 or another suitable network. Each 
merchant 16 communicates with the transaction manager .12 
via a secure link 24. Each financial institution 18 
communicates with the transaction -manager 12 via a .secure 

20 link 22. * 

Each user 14 must register with the transaction manager 12 
whereupon an account is created with the transaction 
manager 12. Information held by the transaction manager 12 

25 in relation to each user is held in confidence and in 
compliance with privacy laws. To register with the 
transaction manager 12 the user 14 must provide the user's 
bank account details including bank account number, 
account type, credit card number, debit card number, 

30 expiry date of each card, credit card limits, along with 
personal details. The account type may be for example 
savings account, cheque account, credit card account, 
debit card account, interest saver account or other types 
of banking or financial institution account. Each user 

35 account created with the transaction manager is provided 
with a transaction manager account number. 



# • 

- 10 - 

The transaction manager account number may be associated 
with a transaction manager account alias such as a name, 
for example "John Doe" . Each alias will need to be unique 
so that no two user aliases can be confused. The user 14 
5 may use the alias to refer to the transaction manager 
account rather than the account number. The transaction 
manager account number is related or mapped to the bank 
account details including the user's bank account number 
or credit card/ debit card number and kept secure. One of 
10 the key advantages of the present invention is that the 
user details including the user's bank account need not 
use the credit card number to conduct financial 
transactions. 

15 A transaction manager account expiry date is provided to 
the account, which is a date on which the transaction 
manager account will cease to be operational. - 

A transaction manager account password is. an optional .j; * 
20 feature that may be included that provides an additional 
level of security before the transaction manager will 
process a transaction. This will be described in further 
detail below. 

25 A plurality of transaction managers 12 may be provided. A 
financial institution may be licensed to operate as a 
transaction manager 12. Transaction managers 12 may be 
geographically located to support a particular region 
according to, for example a licensing agreement. 

30 Transaction managers 12 may communicate with one another 
to process payments. Thus a single transaction manager 
account number can be used for any account of any 
financial institution registered with one of the 
transaction managers 18. 

35 

Financial institution 18 may be for example a bank, a 
credit society, a credit union, building society or any 
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other suitable form of financial institution which have 
accounts within which users can deposit money and the 
money being able to be electronically transferred from 
their account. 

5 

A merchant 16 is a person or entity that uses an on-line 
site, such as an Internet site, to do business with users 
14. Merchants 16 register with the transaction manager 12 
to use the facility provided by the present invention. The 

10 registration process ensures that an e-commerce merchant 
site is a secure site and that Internet clients are 
assured of this certification by the transaction manager 
12. The transaction manager 12 will maintain a database of 
registered e-commerce merchants 16. The e-commerce 

15 merchant 16 also requires a bank account with a financial 
institution 18 in order to receive payments. The 
transaction manager 12 as the intermediatory is trusted by 
the user to process payments^ from the user 14 and* ensure 
they go to the correct merchant 16, only when 

20 appropriately authorised by the user 14.*: . 

Cooperation is required between the transaction manager 12 
and the financial institution 18 of the user 14 to enable 
funds to be transferred at the direction of the 

25 transaction manager 12. The transaction manager account is 
issued to a customer on the basis of understanding between 
transfer manager 12 and the financial institution 18. The 
transaction manager 12 is responsible for security to 
Internet users 14 carrying out their business to customer 

3 0 transaction. 

Referring to Figure 2 , there is shown a communication 
process 26 for the registration of a user 14 with the 
transaction manager 12. A user 14 sends a registration 
35 request to the transaction manager website and requests an 
account. Along with the request for the transaction 
manager account, necessary information for the transaction 
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manager to create the account (such as the personal 
details of the user and banking details of the user with 
their financial institution 18) is sent to the transaction 
manager 12. 

The transaction manager 12 acknowledges the application 
and provided the user 14 meets the transaction manager's 
criteria requests that the financial institution 18 
validate the application. Financial institution 18 either 
accepts or rejects the validation. The transaction manager 
12 then either approves or disapproves of the application 
for registration and sends the appropriate response to the 
user 14 . 

A user 14 may have more than one financial institution 
account linked to the transaction manager account. In this 
case the user 14 provides all the banking* information 
required for the additional .accounts Typically one 
financial institution's account will be nominated as a 
primary account. 

In order to undertake a financial transaction the user 14 
must then request at least one transaction identification 
number. For each transaction that the user 14 wishes to 
make a request must be made for a transaction 
identification number or a request for multiple 
transaction identification numbers must be made. The user 
14 need not do this straight away. The user 14 may request 
additional transaction identification numbers at any 
stage . 

If the user has more than one financial institution 
account related to the transaction manager account, the 
financial institution account used in the transaction 
needs to be specified. This can occur at the time the 
transaction identifier is issued, so that the request for 
the transaction identifier includes nomination of the 
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financial institution account, thus use of the transaction 
identifier will result in the nominated financial 
institution account being used. However the preferred 
option is to allow the user to choose the account at the 
5 time of purchase. This method will be described in more 
detail below. 

If the user 14 decides to make a purchase then they send a 
request* for a transaction identification number to the 

10 transaction manager 12.- The transaction manager 12 then 
provides the requested number of transaction 
identification numbers to the user 14. The transaction 
identification number is provided to a merchant 16 to 
undertake a purchase of a product or service . A 

15 transaction cannot take place until a transaction 
identification number is issued. The issuing of a 
transaction identification number is therefore a* necessary 
step in the processing of a transaction. 

20 The transaction identification number will be sent by the 
merchant 16 to the transaction manager 12. The transaction 
identification number is then used by the transaction 
manager 12 to identify the user 14 and thereby look up the 
user's account to obtain the necessary information to then 

25 conduct the financial transaction. The transaction 

identification numbe'r is a single use number given in 
confidence to the user 14 . Once a transaction 
identification number is used it is not able to be used 
again. The association/mapping between the transaction 

30 identification number and the user's transaction manager 
account is made no longer active. The transaction 
identification number needs to be distinguished from a 
number that may be generated by for example an EFTPOS 
terminal for tracking financial transaction. It also needs 

35 to be distinguished from a credit card number that a user 
provides to a merchant which then can be re-used. 
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The transaction identification number can be a randomly 
generated number or it may be generated by a formula , such 
as a sequentially generated number. It may include a 
checksum or validation digit/s. Further, it may also be 
5 part random and part generated by a formula. 

If the user has more than one financial institution 
account additional details may need to be entered to 
identify the account the user wishes to use. An example is 
10 below: 

When the user 14 makes a purchase they enter 

Account number 
15 Transaction ID 

PIN 

Account Type (2 characters max) 

Should the user 14 have more than one nominated, financial 
2 0 institution account, thpy can leave Account Type null, _in 
which case the transaction is assumed to be using their 
primary nominated financial institution account. 

The account type code can be left null, or have 1 or 2 
2 5 characters . 

Codes are typically 

S = savings 
30 C = cheque 

H = home saver 
V = visa 

A = american express 
M = master card 

35 

Should they only have one nominated financial account they 
leave the account type null . 
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Should they 'have more than 1 nominated financial account, 
for example a savings and a visa, and they wanted to use 
their savings account they would enter S for the account 
5 type. 

If they have more than 1 Visa card (credit card) or more 
than 1 savings account that has been specified as a 
nominated financial account the second account type 
10 character comes in. For example, if they want to use their 
2 nd Visa card they would specify V2 for their account type. 

Users need to be informed of their account type codes when 
the transaction manager account is approved or if the 
15 transaction manager account has been modified by adding an 
additional nominated financial institution account. 

Referring to Figure 3 , a communication,, process 2 8 for a 
merchant 16 registering with the transaction manager 12 is . 

20 shown. Merchant 16 offers its products or services -on-line 
and to register to use the present invention must request 
an account with the transaction manager 12. A request 
along with the appropriate details of the merchant 16, 
including details of the bank account into which transfers 

25 are to be made are provided in a request to the 

transaction manager 12. The transaction manager 12 
acknowledges the application. Provided that the merchant 
16 has a sufficiently secure website and other meets any 
other terms and conditions the transaction manager 12 then 

30 requests validation of the merchant's banking details with 
the merchant's financial institution 18. The financial 
institution 18 either accepts or rejects the validation. 
The transaction manager will then in turn approve or 
disapprove the merchant's application. If the application 
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is approved the merchant 16 will be provided with a 
merchant identification number. The merchant 
identification number is used to identify the merchant 16 
to the transaction manager 12. The transaction manager 12 
is then able to look up the banking details of the 
merchant so that the funds can be deposited in the 
merchant's bank account. 

Referring to Figure 4, the financial institution 18' may 
also required to register with the transaction manager 12 
in order to ensure that appropriate services are provided 
by the financial institution. 18 'to conduct the present 
invention and as a security measure for identifying the 
financial institution 18', thereby ensuring it is not a 
hacker. Registration is also requested of the financial 
institution 18' in order to be licensed to operate as 
another transaction manager. The communication process 
here is shown as 30. The financial institution 18' requests 
an account and provides details to a transaction manager-. 
The transaction manager 12 acknowledges the' application to 
the final institution and requests validation with other 
financial institutions or organisations 18. If the above 
organisations or institutions 18 accept or reject the 
application the transaction manager 12 then forwards an 
approval or disapproval of the application to the 
applicant financial institution 18'.. 

Referring to Figure 5, after the user has obtained a 
transaction identification number the transaction manager 
12 is then able to undertake communication process 32. The 
user selects an item for purchase from the merchant 16. 
The user 12 decides to make a payment to the merchant and 
releases to the merchant the transaction identification 
number and other information required. Other information 
required may include selection of an account type, a 
password, transaction limit, an override password or other 
necessary information. 
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Referring then to Figure 6, which shows communication 
process 34. The merchant 16 sends the transaction 
identification number and other details over the secure 
link 24 to the transaction manager 12. The transaction 
manager 12 then accesses the user's transaction manager 
account 36 using the transaction identification number, 
which also checks whether the transaction identification 
is valid. Matching the transaction identification number 
with the user's account 36 enables the transaction manager 
12 to look up and obtain the banking information in the 
user ' s account 3 6 . 

Referring to Figure 7, which shows communication process 
38. The banking information of the user is then sent in 
the form of a secure financial information to the 
financial institution 18 including, the bank account 
details/credit card details to .the financial institution -.. 
18. The financial institution 18 .then checks, the user's 
financial account information/credit card number in the. 
user's financial institution account 40 to confirm the 
validation of those details and check that sufficient 
funds are available in the user's bank account 40. The 
final institution 18 then notifies the transaction manager 
12 of the validation status and whether it is accepted or 
rejected. 

The amount is transferred from the user's account 40 to 
the merchant's account. 

Referring to Figure 8, which shows the communication 
process 42. The user is that the transaction manager 12 
sends the merchant by secure link 24 the status of the 
transaction and whether it is accepted. If it is accepted 
a transaction tracking number is provided to the merchant 
16. The transaction manager 12 also notifies the user 14 
that the secure transaction has been processed. This may 
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be by e-mail, for example. The transaction manager 12 also 
updates financial information in the merchant's 
transaction manager account 44 along with providing an 
audit trail and updates the financial information in the 
5 user's transaction manager account 36 along with audit 
trail information. 

Referring back to Figure 5, the merchant 16 confirms that 
the purchase has occurred and then provides the goods or 
10 service to the user 14 . 

Referring to Figure 9, flow diagram 50 shows steps for the 
user applying for an account with the transaction manager. 
The process starts at 52 with application for an account 

15 with the transaction manager being made by the user at 54. 
The user submits personal information for the application 
at 56 including banking details. At 58 the transaction 
manager acknowledges to the user the appSlication.and sends 
the information to the relevant organisation of financial' 

20 institution for accreditations. Other organisations may 
include credit rating organisations. 

At 60 the other organisation or financial institution 
validates information sent by the transaction manager. At 

25 62 the other organisation or financial institution advises 
the transaction manager of the validation status. At 64 
the transaction manager determines the status of the 
application according to the validation status from the 
organisation or financial institution and other criteria 

30 that may be applied by the transaction manager and advises 
the user of the status of his or her application. At 66 
the user then receives notification of his or her 
application whereupon the process ends at 68. 

35 Referring to Figure 10 a process 80 is shown with the user 
making a purchase payment for an item. The process starts 
at 82. At 84 the user submits a request for a transaction 
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identification number to the transaction manager. At 86 
the transaction manager receives the request for the 
transaction identification number and performs a 
validation of the user's account, including whether the 
user has an account and whether the account is active. The 
user making the request also provides either their account 
number or their account alias to the transaction manager 
to identify the user. The transaction manager account 
password may be required to authenticate the identity of 
the user. A check is performed at 88 of the validity of 
the user's account. If rejected the process returns to the 
start at 82. If accepted the process moves to 90. The 
transaction manager approves the request and supplies the 
user with one or more transaction identification numbers. 

The transaction identification numbers may be provided on 
a screen for the user to print .out if the request is 
conducted on-line or maybe verbally provided to the user 
if the request is conducted over the telephone or they may 
be electronically transferred* to a storage device/for 
storing the transfer identification numbers. Further 
alternatives for delivering the transaction identification 
number/s include using the postal service to deliver a 
printed list of number/s or a card having a silver latex 
layer covering the number/s, which may be removed by 
scratching similar to instant lottery tickets. 

The user may then leave the transaction manager's website, 
hang up or disconnect the storage device. The user may 
also request a limit be placed on transactions. A limit 
may be provided by default. The value of the limit may be 
modified by the user. If a transaction value is above the 
limit it will be rejected as explained in more detail 
below. The user may have a special reason for overriding 
the normal transaction limit. In this case an override 
password is stored in the user' s transaction manager 
account. Overriding the limit is described below. 
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At a later time the user may visit a merchant's electronic 
commerce shop site on-line at 92. The user selects an item 
for purchase from the merchant's website at 94. Selection 
of an item may indicate the price or the user may be 
required to enter the price in a checkout form. The 
checkout form is required by the transaction manager to be 
an encrypted form when sent between the merchant and the 
user's computer. The usex enters one transaction 
identification number to the checkout form submitted to 
the merchant. This may be by typing in the number into a 
form or by a storage device entering. the transaction 
identification number into the form or transferring it in 
some other suitable manner. If the value of the 
transaction will be above the transaction limit, the user 
may enter the override password. This information is sent 
by secure encrypted submission from the user to the 
merchant. 

At 98 the. merchant acknowledges the secure financial 
transaction to the user. At 100 the merchant then submits 
a secure financial transaction request, to the transaction 
manager. This request will include the transaction 
identification number, the amount of the purchase, the 
merchant's identification and the override password, if 
applicable. At 102 the transaction manager validates the 
secure financial transaction request. If the value is over 
the transaction limit it will be rejected unless the 
override password is provided. The check is performed at 
104, and if rejected such as by the transaction 
identification number not being valid or the merchant's 
identification not being valid as the transaction value 
being over the limit, the process is returned to step 98. 
If accepted, at 106 the transaction manager looks up the 
user's transaction manager account to find the bank 
account details stored in the user's transaction manager 
account and looks up the merchant's banking details. These 



# • 

- 21 - 

are then sent at 108 in an electronic fund transfer (EFT) 
request to the financial institution. The financial 
institution validates the financial transaction request at 
110 and if the validation is rejected, returns a rejection 
message to the transaction manager which will then reject 
the transaction and return the process to 98 . If the 
financial institution accepts the EFT request the process 
moves to 112 where the financial institution transfers 
funds from the user's account to the merchant's account 
according to the details provided by the transaction 
manager. The financial institution then provides a 
tracking number to the transaction manager at 114. At 116 
the transaction manager then informs the manager of the 
transaction approval and provides the tracking number to 
the merchant. At 118 the transaction manager informs the 
user of the successful transaction, preferably by e-mail. 
At 120 the merchants ships the goods to the user and in 
one embodiment also confirms with the user -that the- - 
transaction has been completed^ The- process then ends at 
122 . • 

• * 

The merchant is able to access account history with the 
transaction manager by details stored in the merchant's 
transaction manager account 44. The user is also able to 
access transaction history from the user's transaction 
manager account 36. 

The present invention may also be used to transfer money 
between two or more user accounts or a user account and 
other person's or entity's account. The recipient must be 
a transaction manager account holder. A fund transfer 
request can be initiated by a transaction manager account 
holder. The transaction manager receiving this fund 
transfer request will then relay this request to the 
relevant transaction manager within the transaction 
manager business network. This transaction manager will 
then process this fund transfer request and the recipient 
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transaction manager account will be credited. 

The present invention clearly provides an advantage in 
that the user is not providing their credit card or other 
5 details to the merchant. Instead, they are providing a 
transaction identification number which is a single use 
number. Furthermore, if the transaction requires an amount 
greater than the predefined limit applied to the 
transaction identification number/s but provided that the 

10 amount is within the limits of the user's credit limit 

with their financial institution the user may override the 
transaction limit by providing a password as part of the 
transaction process. In addition, the transaction manager 
operates as more than just a clearing house in that it is 

15 an organisation trusted by the user that conducts the 

electronic fund transfer with the financial institution. 

Due to transaction identification hunjbers .being single use 
the user has peace of. mind in thai: "they do not-'have to ber-. m m 
20 concerned with the merchant keeping, a copy of the 

transaction identification number as it' Will not be 
useable again. This is unlike a credit card number which 
may be re-used or potentially fall into the wrong hands. 

25 Modifications and variations may be made to the present 
invention without departing from the basic inventive 
concept. Such modifications are intended to fall within 
the scope of the present invention, the nature of which 
are to be determined from the foregoing description. 
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Figure 3 shows the link between . a Merchant 

and a Transaction Manager during the Application for an Account. 
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FIG. 3 



Figure 4 shows the link between a Financial 

Institution or Bank and a Transaction Manager during the Application for an Account. 
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Figure 7 shows the link between a Transaction Manager and a 
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Figure % shows . the link connecting a Transaction Manager, a 

Merchant and a User 
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FIG. 3 



Figure S shows the Flow Diagram of a User applying for an account with a 
Transaction Manager. 
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Figure lOshows the Flow Diagram of a User making a purchase and paying for the 
item(s). 
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